[BREAKING] feat: Support passthrough API#70
[BREAKING] feat: Support passthrough API#70khanhtranngoccva wants to merge 38 commits intoAlogani:develfrom
Conversation
|
Note: this PR is bleeding edge and uses a forked version of |
|
Hi khanhtranngoccva, As for my other comments, having code mixed from different PRs doesn't help me understand your intent and changes (even i you mentioned this PR is not to be merged yet). This is an interesting idea and i understand the attraction of using passthrough of fuse. However i am not familiar with it, can't using passthrough API allow to not use at all InodeMapper API ? It would be interesing to allow a full delegation of inodes handling to the final user (for example, the user would provide the inodes of an existing unix filesystem). However providing this ability would introduce a lot of breaking changes in how it is handled right now (and i haven't the impression this is how you decided to handle it). If that is the case, it would be better to allow the final user to provide its own InodeResolver through dependency injection. But, even if it seems a nice feature, is there really a use case for such a niche feature? If a user want to go so low level, it would be better to use directly fuser crate than my "high level" easy_fuser. |
|
This PR is superseded by #73. |
2 participants
The
fusercrate supports passthroughs and it is possible that a user wants to forward most or all operations directly to the kernel instead of handling FUSE manually. Theopenandopendirmethod now exposes an extra objectOpenHelperthat allows users to allocate a backing ID by callingopen_backing, and the ID should be returned by these methods. The user also no longer needs to manually manipulateFUSEOpenResponseFlags.